AUTO-DETECTION OF ISDN BRI SERVICES 



FIELD OF THE INVENTION 
This invention pertains generally to Integrated Services Digital Network 
5 (ISDN) terminal equipment, and more specifically to the configuration and setup of 
ISDN features on terminal equipment. 

BACKGROUND OF THE INVENTION 
ISDN offers customers a digital connection to their telephone service provider, 
using the same phone lines that are used for conventional analog phone service. 
10 Figure 1 illustrates ISDN Basic Rate Interface (BRI) service, which operates across a 
single twisted pair local loop 22 (the U interface in ISDN terminology). One end of 
local loop 22 terminates at the telephone service provider's ISDN switch 24, typically 
located at a central office. ISDN switch 24 connects in turn to network 26, allowing 
ISDN customers to connect, e.g., calls to circuit-switched telephone equipment 28, or 
1 5 data connections to packet-switched data terminal equipment 30. 

At the customer's end of local loop 22, a network termination 32 converts 
between the U interface signal and a four-wire S/T interface digital signal (a T 
interface is point-to-point, while an S interface is point-to-multipoint). An S interface 
34 is shown connected to several types of terminal equipment. ISDN telephone 36 is 
20 provisioned for direct connection to S interface 34. Router 38 is also provisioned for 
communication over S interface 34, and connects, e.g., to local area network 40. 
Terminal adapter 42 formats conventional analog circuit-switched signals, e.g., from 
an analog telephone 44 or an analog computer modem 46, to an ISDN digital carrier 
format. Other types of terminal equipment, such as PBX equipment, credit card 
25 authorizes, etc., (not shown) may also connect to S interface 34. 

ISDN BRI service provides three bi-directional channels on an ISDN 
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connection. Two of these channels are B (bearer) channels, B 1 and B2, and the third 
channel is a D (delta) channel. Each B channel has a 64 kbps (thousand bits per 
second) data rate, and can be used for voice or data. Thus at any given time, an ISDN 
BR1 can support, e.g., two voice calls, or a voice call on B 1 and packet data transfer 

5 on B2, or 128 kbps packet data transfer using both Bl and B2. The D channel has a 
16 kbps data rate, and is used for exchanging call set up and signaling messages for 
the B channels. The D channel can also be used to send and receive X.25 packet data. 

One disadvantage of ISDN is that setting up and configuring terminal 
equipment can often be a daunting task for a novice. For instance, when equipment is 

10 physically connected to an ISDN line, the basic layer 2 transport mechanism is 

enabled. But most useful communications with the provider's ISDN switch will be 
disabled unless the terminal equipment knows its Service Profile Identifier (SPID), 
which is usually its 10-digit directory number with or without other strings of digits 
concatenated with it. It is also useful if the terminal equipment knows the type of 

15 ISDN switch it is connected to, since each type of switch may have certain functional 
peculiarities that can be compensated for by the terminal equipment. Finally, there 
are also a range of secondary data and/or voice services/features that may or may not 
be implemented on this particular ISDN switch and/or line. 

Recent advances in ISDN have created a mechanism whereby terminal 

20 equipment can automatically obtain a list of valid SPIDs from the switching system, 
allowing the equipment to auto-configure its SPID. An Automatic Switch Detection 
process also now allows terminal equipment to determine the type of ISDN switch 
(e.g., 5ESS, DMS-100) that it is connected to. But no mechanism currently exists for 
automatically determining which, if any, secondary services/features are available on 

25 the ISDN line. 
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SUMMARY OF THE INVENTION 
Currently, the only way to know if ISDN secondary services/features exist on 
an ISDN line is to examine the provisioning information obtained from the ISDN 
service provider. Quite often this information is inaccurate or not readily available. 
5 And to a novice, this information may not make much sense even when it is available. 

The embodiments described herein provide for auto-detection of various ISDN 
supplementary services or features. These embodiments greatly increase the usability 
of an equipped device. For instance, the available supplementary services can be 
summarized for the user, making setup, debug, and device use easier. Network 
10 management software can also use information about available services to auto- 
configure the device, flag conflicts between the present configuration and the 
available services, and/or present configuration options that show only available 
features. Finally, during troubleshooting, the auto-detection information can be used 
to locate configuration problems, rule out problems at the switch, etc., without the 
15 troubleshooter having to decode cryptic messaging between the switch and the 
terminal equipment. 

In one aspect, the present invention comprises a method for operating ISDN 
terminal equipment connected to an ISDN network via an interface having at least 
two B-channels and one D-channel. The method transmitting an auto-request, for an 
20 ISDN transaction that exercises an ISDN supplementary service, to the ISDN network 
across the ISDN D-channel, and receiving an acknowledgment across the D-channel 
related to the auto-request. The acknowledgment is evaluated to determine whether 
the auto-request was successful. 

In a second aspect, the present invention comprises an ISDN terminal endpoint 
25 having an ISDN communication protocol stack and an automatic supplementary 
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service detector. The automatic supplementary service detector communicates with 
the ISDN communication protocol stack to generate an auto-request for an ISDN 
transaction that exercises an ISDN supplementary service, and to evaluate the success 
of the auto-request. Based on the results of this request, the detector preferably 
provides an indication of whether the supplementary service is available for use. 

In a further aspect, the present invention comprises a computer-readable 
medium containing a program for detecting whether one or more ISDN 
supplementary services are available on an ISDN BRI, the program having an auto- 
request generator, an auto-request evaluator, and a service availability indicator. 
BRIEF DESCRIPTION OF THE DRAWING 

The invention may be best understood by reading the disclosure with reference 
to the drawing, wherein: 

Figure 1 provides an ISDN system overview; 

Figure 2 shows message flow for an auto-detection process according to one 
embodiment of the invention; 

Figure 3 shows blocks for an auto-detect according to another embodiment of 
the invention; 

Figure 4 shows a process for implementing auto-detection of a call 
conferencing feature according to an embodiment of the invention; and 

Figure 5 shows a process for implementing auto-detection of X.25/D channel 
availability according to an embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The following terms have defined meanings within this specification. An 
ISDN terminal endpoint is a customer-end ISDN device having at least layer 2 and 
layer 3 ISDN protocol stack functionality — the device may connect to an ISDN line at 
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the S, T, or U interface. An ISDN communication protocol stack includes at least 
ISDN layer 2 (e.g., Q.931) and ISDN layer 3 (e.g., Q.921) functionality. An ISDN 
supplementary service is a service that provides more than just basic B channel call 
completion — for example, D channel data service, or call services such as call hold, 

5 call conferencing, call waiting, call transfer, and call forward. An auto-request is a 
service request that is generated by a terminal endpoint in order to determine the 
availability of the service. Finally, a device configuration register provides for storing 
the results of automatic supplementary service detection. 

Referring now to Figure 2, message flow for one embodiment of the invention 

10 is depicted. In this embodiment, terminal equipment 50 runs several processes, 

including ISDN stack 52, auto-detector 54, and user interface 56. User interface 56 
initiates the auto-detect sequence, when requested by a user, by signaling auto- 
detector 54 to detect either the availability of a single supplementary service/feature, 
or of all such services/features. Assuming for purposes of this illustration that auto- 

15 detection of a single service is requested, auto-detector 54 generates an appropriate 
stimulus to ISDN stack 52, triggering an ISDN event that can be used to test the 
service or feature. ISDN stack 52 and ISDN switch 24 pass Q.921 /Q.931 messages 
related to the event, resulting in one or more codes being returned to auto-detector 54. 
Auto-detector 54 evaluates these codes to determine whether the service auto-request 

20 was successfully granted, and passes an indication of service availability to user 
interface 56. 

Figure 3 shows a block diagram of one embodiment of auto-detector 54, 
illustrating several processes or threads that exist in this embodiment. During 
operation, service availability indicator 64 accepts requests from the user interface to 
25 initiate auto-detection of a supplementary service. Indicator 64 signals auto-request 
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generator 60 that a service is to be tested, causing generator 60 to dispatch an 
appropriate stimulus to the ISDN stack. 

Messages passed back from the ISDN stack are interpreted by auto-request 
evaluator 62. Generator 60 informs e valuator 62 of what was requested. Evaluator 62 

5 compares the messages it receives from the ISDN stack to the expected messages for 
the requested event. When the message is expected in an intermediate step for the 
detection of the feature, evaluator 62 informs generator 60 that it can proceed with the 
next stimulus in the detection process. When the message conclusively determines 
the availability or unavailability of the service, evaluator 62 sets device configuration 

10 register 66 appropriately. 

Device configuration register 66, as shown, can be accessed by service 
availability indicator 64 or by the user interface directly. In alternate 
implementations, only one of these paths need exist, and device configuration register 
66 can even be maintained by a process separate from auto-detector 54. It is 

15 preferable, however, that auto-detector 54 be able to read from as well as write to this 
register, in order to examine prior auto-detect results and user configuration. 

Figure 4 shows an auto-detect process for one particular calling feature, i.e., 
call conferencing. In call conferencing, three (sometimes more) parties to a call can 
each hear all other parties and be heard by all other parties. In the embodiment of 

20 Figure 4, the availability of this service is auto-detected by actually proceeding 

through the initial phases of a call conferencing setup using the ISDN connection's 
channels. 

The process shown in Figure 4 is initiated at block 70, e.g., when call 
conference service is to be detected as described above. At block 72, the ISDN 
25 switch type of the switch servicing the ISDN connection is retrieved — this may 

Patent Application 6 Do. No. 2705-304 

Seq. 8215 



already exist in a device configuration register, or it can be discovered by a prior art 
automatic switch detection process. At block 74, if the switch type is known to not 
support conferencing, no further action will be taken and control will transfer to block 
90 for indication that call conferencing is unavailable. 

5 If the switch can possibly support conferencing, or its capabilities are 

unknown, a call is requested to one of the terminal equipment's directory numbers (it 
may have one or more directory numbers assigned). For instance, in block 76 an 
outgoing call using bearer channel Bl is initiated by appropriate D-channel signaling. 
Since the call is to the equipment's own directory number, D-channel signaling for an 

10 incoming call will also be received, and the call is answered using bearer channel B2 
at block 78. At this point, a two-way call using both ISDN B channels has been set 
up. 

Once the two-way call has been set up, the auto-detector next attempts to place 
one end of the call on hold at block 80. For instance, the "calling" end associated 

15 with Bl can request a HOLD, or the "called" end associated with B2 can request the 
HOLD. If the hold request is successful, a HOLD ACK should be received from the 
switch (note that this also indicates that the call hold feature is available). If HOLD 
ACK is not received, control is transferred at block 82 to block 90 for indication that 
call conferencing (and possibly call hold) is unavailable, since the first call could not 

20 be placed on hold. 

When HOLD ACK is received, block 82 transfers control to block 84 for call 
setup to a second number. If the ISDN connection has more than one directory 
number, this call can be directed to the second number. Another possibility for call 
direction is a pre-programmed 1-800 number. In either case, it is not necessary that 

25 the second connection actually be completed. 
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Block 86 looks for a CALL PROC message from the switch, indicating that 
the second call setup is proceeding. When a CALL PROC message is received, the 
auto-detect process can abort connection of the second call and transfer control to 
block 88 for indication that call conferencing is available. If the call does not 
5 proceed, control is transferred to block 90 for indication that call conferencing is 
unavailable. 

It may be possible that call conferencing availability depends on whether the 
endpoint requesting conferencing is the "calling" or "called" party. Both cases can be 
tested by proceeding through block 86 by requesting the hold on Bl, and then taking 

10 the line off hold, returning to block 80, and repeating steps 80-86 by requesting the 
HOLD and CALL SETUP on B2. 

Other supplementary calling features can be tested in a manner similar to that 
shown in Figure 4. For instance, the call waiting feature signals that a call is 
incoming on a directory number that is already in use. This feature can be tested by 

15 setting up a first call (e.g., to a known number) using the directory number to be 
tested as the outgoing number, and then setting up a second call to the directory 
number using the other B channel. If the feature is enabled, D channel signaling 
should be received indicating that an incoming call is waiting. The auto-detect 
process can end at this point, or the auto-detector can execute a switchover from the 

20 first to the second call and evaluate the success of the switchover. Likewise, the 
disable call waiting feature can be tested by initiating the first call with a proper 
disabling prefix digit string, and then testing that a busy signal is received on the 
second call. 

Examples of other features that can be detected with two directory numbers 
25 are call transfer and call forward. Call transfer can be detected by initiating a first call 
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using Bl to one of the directory numbers, answering the "incoming" call on B2, 
placing the incoming call on hold and requesting that it be transferred to the other 
directory number. This should generate appropriate D-channel signaling indicating 
whether the feature is available. Likewise, call forwarding can be detected by 
5 requesting that calls to one directory number be directed to the other, placing a call to 
the forwarded number and looking for signaling indicating that a call is incoming on 
the second directory number. 

A second group of supplementary services that can be detected in an 
embodiment of the invention are the D-channel data services, particularly X.25/D 
10 packet data service. Since it is highly unlikely that signaling traffic will ever require 6 
kbps or more of the D-channel bandwidth, ISDN allows the excess capacity of the D 
channel to be allocated for data transfer. X.25/D packet data service can use up to 9.6 
kbps of the 16 kbps capacity of the D channel for data transfer according to the X.25 
packet format. 

15 All traffic over the D channel uses a frame-based link-layer protocol known as 

LAPD (Link Access Protocol-D channel), as defined in Q.921. This service, when 
available, should support multiple logical LAPD connections. The connection to 
which a particular frame belongs is determined by examining several frame fields, 
including the service access point identifier (SAPI) and the terminal endpoint 

20 identifier (TEI). 

The SAPI identifies the higher-layer protocol embedded in the data field of the 
frame. For instance, SAPI^O identifies the frame as a call control frame that manages 
the B channels, SAPI=16 identifies the frame as an X.25 frame, and SAPI=63 is used 
for layer 2 TEI assignment. 

25 The TEI identifies an ISDN device. When several devices use the same ISDN 
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link (i.e., share a common S-interface), the TEI allows them to be distinguished. Thus 
on that interface, the TEI for each connected device must be unique, although a device 
may support multiple TEIs (e.g., one for each B-channel and one for X.25/D-channel 
data transfer). TEIs from 0 to 63 can be fixed by the ISDN service provider. TEIs 
5 from 64 to 126 are available for use during automatic TEI assignment using the Q.921 
management functions. And TEI=127 is a broadcast TEI that can be used by devices 
having no assigned TEI. 

Referring to Figure 5, the X.25/D detection process is initiated at block 100. 
At block 102, an Identity Request message is sent to the network. This Q.921 frame 

10 requests a TEI to be used with X.25/D services, by including in the frame fields a 

SAPI of 16, a "dummy" placeholder for the TEI, and an Action Indicator (Ai) of 127. 
An Ai of 127 indicates that a TEI is being requested. 

At block 104, the Q.921 frame received from the network is examined. If a 
TEI was automatically assigned, the Q.921 frame will contain an Identity Assigned 

15 message that will indicate the assigned TEI. In this instance, X.25/D service is 

available, and this can be indicated by a transfer of control to block 1 1 8. The network 
may alternately return an Identity Denied message, which could indicate that X.25/D 
service is unavailable. But the Identity Denied message could also indicate that a 
fixed or automatic TEI has already been assigned to this equipment. 

20 To check the latter case, a message-generating loop steps through the 

possibilities for a pre-assigned TEI. Specifically, one possible implementation of this 
loop is shown at blocks 106-1 14. Block 106 sets a TEI of 0. An Identity Request 
message is then transmitted to the network, as a Q.921 frame with the fields SAPI=16, 
TEI=TEI, and Ai=127, at block 108. A decision block 1 10, similar to decision block 

25 104, checks the return message from the switch. If the return message indicates 
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success, X.25/D service is available at TEI=0, and control can be passed to block 118 
for indication. 

If the return message indicates failure, other values of TEI are tried. The value 
of TEI is incremented by one at block 1 12, and block 108 executes again. When TEI 
5 steps out of the valid assignment range (i.e., TEI = 127), block 1 14 detects the 

condition. At this point, it is finally conclusively determined that the X.25/D service 
is unavailable, and control is passed to block 1 16 for an appropriate indication of the 
lack of service. 

An auto-detector according to an embodiment of the invention can be 

10 activated in a number of ways. Terminal equipment can include an "auto-detect" or 
"auto-con figure" button, or its equivalent as a selectable option in software. The 
auto-detector can be activated when the system boots after initial connection to an 
ISDN line, or after a loss of configuration memory. Or, the auto-detector can be 
activated from a debugger or other diagnostic tool. The auto-detect can be configured 

15 to detect all known secondary features, or a selectable subset. 

The auto-detector can be implemented in a variety of types of terminal 
equipment. For instance, an ISDN telephone can use the auto-detector to configure 
supplementary call features. An ISDN terminal adapter can provide an analog phone 
user with voice messages, etc., if the user tries to access a feature that is not 

20 implemented at the switch. And PBX or router equipment can use the auto-detector 
for auto-configuration, setting up the fields in a configuration database for a network 
management agent, or during diagnostics. 

The disclosed embodiments presented herein are exemplary. Although the 
embodiments are illustrated using specific ISDN protocols, it is recognized that 

25 modifications to and/or substitutions for these protocols may occur in the future, and 
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the use of any specific protocol herein is for convenience of description. 
Furthermore, the protocol level at which an auto-detect process communicates with 
the ISDN stack can be varied to suit the requirements of specific implementations, 
e.g., some auto-detect features are more appropriate as a layer 3 entity, others are 

5 more appropriate as an entity at layer 4 or above, etc. It is also recognized that 
systems implementing the invention can be distributed, i.e., that software/hardware 
used during auto-detection may be divided into several sections, residing respectively 
on multiple physically separate but network-connected platforms. Various other 
modifications to the disclosed embodiments will be obvious to those of ordinary skill 

10 in the art upon reading this disclosure, and are intended to fall within the scope of the 
invention as claimed. 
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